CONTROL MESSAGING FOR AN ENTERTAINMENT AND 
COMMUNICATIONS NETWORK 



DESCRIPTION 

RELATED APPLICATION 

5 The present application is related to U.S. Patent Application No. 

09/ (Attorney Docket No. 7261-68779) entitled "'DIGITAL MULTI- 
ROOM. MULTI-SOURCE ENTERTAINMENT AND COMMUNICATIONS 

NETWORK" to Tomassetti et al; U.S. Patent Application No. 09/ 

(Attorney Docket No. 5969-69492) entitled "A DATA STRUCTURE FOR AN 
1 0 ENTERTAINMENT AND COMMUNICATIONS NETWORK" to Tomassetti et 

al; U.S. Patent Application No. 09/ (Attorney Docket No. 5969- 

69493) entitled "INITIALIZATION METHOD FOR AN ENTERTAINMENT AND 
COMMUNICATIONS NETWORK" to Tomassetti et al., all filed coincident 
herewith and assigned to the assignee of the present invention. 

1 5 BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention is related to peer-to-peer local area networks (LANs) 
and. more particularly to controlling a peer-to-peer local network wherein control 
data and information, especially multimedia information, is provided to stations 
20 connected to the network. 



5569-69491 



-1- 



Background 



A typical audio system has a centralized receiver that includes a tuner and 
program function selector (where a program source is selected) and one or more sets 
of speakers, e.g., a local speaker set and remote speaker sets. The centralized 
5 receiver controls the volume at all speaker sets, i.e., on both the local speaker set and 
on the remote speakers. The receiver selects a single program source for play at any 
and all of the speaker sets. Only one source is selected and available at all of the 
speaker sets at a time, even though the receiver may have inputs from multiple 
devices. Input devices ma}' include, for example, a turntable, tape player, a compact 
1 0 disc (CD) player, a minidisk (MD) player and other auxiliary devices, such as a 
digital audio tape (DAT) player, a digital versatile disc (DVD) player, a 
videocassette recorder (VCR) or television set. 

Transferring multimedia information over a network is known, e.g., steering 
multimedia data over a network such as the internet or a local area network (LAN). 

1 5 The multimedia data may be raw audio or video data such as a wave file, a bitmap or 
a movie file. However, typically, multimedia files are compressed using, for 
example, the motion pictures expert group (MPEG) format to reduce the data 
volume that must be handled. Furthermore, music or songs may be encoded as 
compressed audio, for example, using the MPEG layer 3 (mp3) standard. This 

20 compressed audio may also be made available as an mp3 file for compact storage, 

transport and handling. Depending upon the complexity of the audio source file that 
is compressed, these audio compression techniques can reduce file size by 90% or 
more, without losing playback quality, i.e., with CD quality playback. 

Reduced file size and CD quality sound have made compressed audio files 
25 very popular. So, mp3 file libraries are available at numerous internet sites, e.g., 
mp3.com or napster.com. Further, various software interfaces are available for 
playing mp3 files, either directly, as they are downloaded to a personal computer 
(PC) from the internet or, from a cache of previously downloaded mp3 files, e.g., 
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Winamp and RealPlayer. Software packages are also available to encode 
uncompressed audio, e.g., encoding a music cut from, for example, a CD into a mp3 
file. After encoding (called ^ripping") the condensed file may be stored on a PC 
either for subsequent playback at the PC or, for transfer to a dedicated mp3 player, 
5 such as the Lyra from RCA or the Rio from Diamond Multi-Media. 

A typical such mp3 player looks like a small (about the size of a cigarette 
package) personal radio with mini-earphones for private listening. Usually, the mp3 
files are stored in non-volatile memory in the mp3 player, which may hold an hour 
or more of encoded music. These dedicated mp3 players normally serve as personal 
1 0 music players that provide a single individual with music and songs selected for the 
listener's taste. 

Another well-known way to deliver multimedia data to an individual is to use 
streaming audio/video, W'herein multimedia data is continuously sent over a network, 
e.g.. the Internet, and displayed/played on a computer as it is received. Numerous 
15 websites are available, currently providing streaming audio, e.g.. broadcast.com. 
Still other sites include links to multimedia files that play as they are downloaded. 
However, these files use standard hypertext transport protocol to deliver the files, 
which are named to invoke a particular browser plug-in, such as RealPlayer, which 
plays the file. 

20 Although the personal mp3 players may be attached to a sound system, e.g.. 

as an auxiliary device, usually they are not. So, for example, a musical piece being 
played on a turntable attached to a sound system is not heard through speakers 
attached to a computer: and. streaming audio or a mp3 file being played on a 
computer is not easily diverted to a home theater system. 

25 Consequently, heavy metal music, downloaded by a teenager and being 

played on a PC in the teen's room, may be disturbing everyone else in the house, 
while a sound system that is intentionally located in a remote, isolated family room 
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may lie dormant. Light music that is being piped throughout the house from a sound 
system located in the family room and, played at a volume that is barely loud enough 
to be heard in the crowded family room, may be overly loud in another, nearly empty 
room. By contrast, the same music set at low volume in a nearly empty family room 
5 might not be heard in other rooms where people are standing and chatting. 

Thus, there is a need for a multimedia system wherein multiple streams of 
data may be sent and received simultaneously and independently controlled such that 
a program source in one or more zones or rooms can stream multimedia data that is 
passed to one or more other zones or rooms, w ; here it may be independently selected, 
1 0 controlled and played. 

SUMMARY OF THE INVENTION 

It is therefore a purpose of the invention to control distribution of digital 
audio to different zones within the same structure; 

It is another purpose of the invention to control independent distribution of 
1 5 separate audio data streams to different zones within the same structure; 

It is yet another purpose of the invention to share digital audio between zones 
in a structure; 

It is yet another purpose of the invention to control communication between 
nodes on a peer-to-peer audio network; 
20 It is yet another purpose of the invention to control multiple streams of data 

streaming simultaneously and independently between individual nodes of a peer-to- 
peer network. 

The present invention is a control messaging structure for a multi-zone 
entertainment and communications network and control method therefor. The 
25 network is a digital peer-to-peer network distributing data that is being streamed 
from multiple independent entertainment and communications media sources to 
multiple independent receivers and/or transceivers. The receivers and transceivers 
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may be located in different zones from each other. The zones may be individual 
rooms of a building or house. The control messaging structure is a peer-to-peer 
communication protocol structure. Feature cards or remote devices are connected to 
peer nodes, which are controlled by control data passed between the nodes on the 
5 network over a control bus using the preferred control messaging structure. 

Likewise, information is shared over the control bus between devices connected to 
network nodes using the control messaging structure of the present invention. 

The preferred control message structure is a bjte serial data stream wherein 
one byte per packet is passed over the control bus between communicating nodes. 

10 The control message includes a preamble, a destination address, a source address, a 
payload and a checksum A field may also be included to designate payload size 
allowing a variable sized payload. Each node uses messages structured according to 
the control message structure to communicate with other nodes, gain access to the 
network, arbitrate contention for the control bus. and detect collisions with messages 

1 5 from other nodes. 

All active nodes constantly monitor the control bus for activity. When the 
control bus is quiet, any node with control/data to be sent, can begin transmission, 
sending a request for access to initiate contention arbitration for the control bus. 
Then, the requesting node monitors a corresponding return message. If the return 
20 message mirrors the request, the node has access to the bus and, the node may write 
a message to the control bus. structuring the message according to the control 
messaging structure of the present invention. If access is denied, then, the node must 
wait until the control bus is idle again before re-attempting to initiate contention 
arbitration. 

25 Advantageously, the messages between nodes remains synchronous, allowing 

each node and feature card connected to the network to communicate with all other 
connected remote locations. Further, the preferred control messaging structure 
enables communication in multi-zone media network so as to make digital audio 
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available to each zone of a building or other structure, such as through different 
room stations of a house. Also, the room stations can individually inject control data 
into the data stream and onto the network. Alarms or other minimal functionality 
features may be included, such as to the ability to monitor another remote station 
using the multi-zone media network's intercom function. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advantages will be better 
understood from the following detailed preferred embodiment description with 
reference to the drawings, in which: 

Figure 1 is schematic representation of a basic example of a local 
communication network according to the preferred embodiment of the present 
invention: 

Figure 2 is an of the basic local communication network of Figure 1 ; 

Figure 3 is a block diagram of the preferred embodiment hub module; 

Figures 4A-B show a timing diagram and data structure illustrating how 
messages and data are exchanged between the local nodes and the remote nodes 
across the backplane; 

Figure 5 is an initialization timing diagram; 

Figure 6 is a state diagram showing how the preferred local communication 
network ma> be initialized: 

Figures 7A-B show a state diagram and control data structure in an example 
of how a node may gain access to the control bus: 

Figure 8 is an example of a state diagram for message reception control; 

Figure 9 is an example of a typical preferred embodiment home 
communication system; 

Figure 10 is an example of the room station; 

Figure 1 1 is a block diagram of a remote station: 




Figure 12 is a block diagram of the digital loop filter. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE 

INVENTION 

Referring now to the drawings, and more particularly, Figure 1 is a block 
representation of a basic local communication network 100 according to the 
preferred embodiment of the present invention. In this example, the network 100 
includes an expandable hub 1 02 that may include one or more hub modules 1 04, 
(two in this example) which are attached to and in communication with each other 
over a back plane 106. In addition, one or more local feature cards 108 may be 
locally attached to the back plane 106 for direct communication to the expandable 
hub 102. Remote stations 110 and remote feature cards 1 12 may be located in 
remote zones (e.g.. different rooms) and connected to the hub modules 104 over 
individual high speed data communications channels 114. e.g., a pair of Ethernet 
adapters sending/receiving a high speed (lOMbit/second) serial data stream over a 
twisted pair. The hub modules 104 and any optional local feature cards 108 may be 
aesthetically encased in a structured wiring cabinet (not shown) to give the 
appearance of a typical state of the art home entertainment system. For convenience, 
an expandable arrangement 102 of hub modules 104 and optional feature cards 106 
are referred to hereinbelow, generically, as an entertainment hub 102. 

20 Thus, in this example, each hub module 104 includes hub ports 1 16; each 

local feature card 108 includes a local node 118; and, remote nodes 120 are included 
in each remote station 1 10 and each remote feature 1 12. The hub ports 1 16 are 
interfaced to the back plane 106. each connecting a remote device, i.e.. connecting a 
remote station 1 10 or feature card 1 12, to the network. The local nodes 118 

25 interface the corresponding function of a local feature card 108 to the back plane 

106. The remote nodes 120 interface the multimedia function of the remote stations 
110 and the remote feature cards 1 12 to the hub ports 116, providing and receiving 
data in a format suitable for inter unit serial data communication. 



10 
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Figure 2 is an example of the basic local communication network 100 of 
Figure 1, which is. essentially, a peer-to-peer network of digital audio devices. 
Typically, a preferred embodiment system 100 includes a single entertainment hub 
102. However, it is understood that multiple entertainment hubs 1 02 may be 
included communicating over connected backplanes 106, e.g., with a network 
bridge. Further, the entertainment hub 102 may be located at a convenient location 
within a structure, such as a home, with the remote stations 110 and the remote 
feature cards 1 12 being located throughout the structure in different zones, i.e., in 
different rooms. In addition, in the basic example of Figure 2, a 
media/communications face plate is shown as an example of a local feature card 
108. In this example, the face plate includes a stereo audio input 122 (left and right), 
a stereo audio output 124 (both left and right) and an optional infrared (IR) port 126 
for control. As further depicted, the IR interface 126 may include a separate infrared 
receiver jack 1261 and an infrared emitter jack 1260 or a suitable bidirectional IR 
port may be substituted. Preferably loud speakers 127 are attached to the room 
stations 110, 120 for playing music, receiving intercom information or, listening to 
other stations. 

Figure 3 is a block diagram of the preferred embodiment hub module 104 
according to the present invention. As can be seen, the preferred hub module 104 
includes preferably four hub ports 1 1 6. Each hub port 1 16 can interface up to four 
unique audio source address locations and one intercom source which shares a 
common address with the first audio source address. Each hub module 104 includes 
a serial interface that may be a local area network (LAN) or serial data interface 
function, in the example an Ethernet physical layer (Ethernet phy) 128, that connects 
the serial channel 1 14 to the hub ports 1 16. A hub interface 130 interfaces the hub 
ports 1 16 to the backplane 106. 

The serial data interface 128 may be readily available Ethernet chip such as, 
for example, the LU3X3 1T-64 FASTCAT phy chip interface (phy chip) from Lucent 
Technologies, the LTX905A Universal 10BASE-T Transceiver from Level One or 




an equivalent. Preferably, the hub ports 116 and hub interface function 130 are in a 
single integrated circuit chip such as the Altera 6024, 1 OKI 30 or an equivalent. The 
hub interface function 130 includes a hub port audio channel selector 132 passing 
digital audio and intercom data between the hub ports 1 16 and the back plane 106 
through an audio/intercom buffer 134. A back plane controller 136 conducts device 
address polling/acquisition, selectively passing a unique product serial number for 
each of the attached devices and, when set as master (as described hereinbelow), the 
master backplane controller controls other attached hub modules 104 during such 
operations. The backplane controller 136 either actively drives bus signals at the 
backplane 106 or passively through the dot OR outputs of drivers 138 which are dot 
connected to other attached devices, A non- volatile storage interface 140 provides 
an interface to non- volatile storage 142, e.g., EEPROM. The non-volatile storage 
142 is included in the hub module 104 for maintaining address assignments, etc., 
during power off. In the example of Figure 2, the non-volatile storage 142 is 
provided for address and configuration data local storage at the hub module. 

Thus, each remote node 120 is connected to a hub port 116 over a serial 
channel 1 14 using a suitable serial communication medium. The serial channel 1 14 
ma) 7 be a twisted differential pair connected at each end to an appropriate signaling 
20 interface, preferably, conforming with the Institute of Electrical and Electronics 

Engineers (IEEE) 802.3 specification for Ethernet, such as the above mentioned phy 
chip. Alternatively, an universal serial bus (USB) interface or an IEEE 1394 fire 
wire interface may be substituted for the Ethernet interface without departing from 
the scope of the invention. Further, standard category 5 (CAT 5) wire (4 twisted 
25 pairs) is preferred for the high speed data communications media in the channel 1 14 
connecting the entertainment hub 102, i.e., the remote stations 110 and remote 
feature cards 1 12 to the hub modules 104. The serial data interface 128 passes 
locally synchronized serial data from the high speed serial channels 1 1 4 to/from the 
hub ports 116. The hub ports 116 convert the serial data from serial data interface 
30 128 to parallel data which is passed to the backplane 106 and vice versa. 



10 
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Pulse Transformers (not shown) in each of the remote nodes 120 and hub 
ports 116 provide signal isolation. The hub modules 102 provide power to 
connected channels at a level sufficient to power a 10W Class D amplifier at each 
station, Channel power is forty eight volts (48V) DC and is distributed through two 
5 pairs of conductors of the CAT 5 cabling, passed through to the wiring at the hub 
port 1 16 pulse transformers center taps. The current is extracted on the receiving 
end to power the remote nodes 120, drawn from the four current carrying CAT 5 
conductors and the center taps of the remote node transformers. 

For additional efficiency, the serial data clock for each channel (remote node 
10 120 - hub port 1 16 connection) may be embedded into packet data for that channel 
using, for example, the well known Manchester encoding technique. Thus 
embedding the serial data clock also balances the data stream, thereby nearly 
eliminating the exposure to saturation in the pulse transformer. Once embedded in 
the data stream, the clock may be extracted from the data stream using a phase 
1 5 locked loop (PLL) with the link pulse function indicating the existence of a 

connection between each hub port 116 and its corresponding remote node 120. 

Data is transferred between the hub modules 102 and the remote nodes 120 
using a non-Ethernet serial data frame structure at a preferred transfer rate of 
lOMb/s. Preferably, data is transferred in full duplex, each packet being 

20 synchronized with the hub backplane. The packet structure is fixed, preferably at 

197 bits, and includes a preamble field, a control bus status field, and specific frames 
for audio (Laudio 1-4 and Raudio 1-4), intercom (Icom), hub control, and for data 
control. The preamble is a signature bit stream, preferably 24 bits, for synchronizing 
the physical layer PLL of each channel. The control bus status (CBS) field may be a 

25 single bit field that indicates when the control bus is active. The eight audio frames 
(Laudio 1 - 4 and Raudio 1 - 4). two each per channel, each channel having enough 
bandwidth to pass compressed or uncompressed audio data to/from the remote 
nodes, preferably two eighteen bit stereo frames for each channel. Since the 
intercom channel is intended to carry only voice data, the Icom frame need not be as 
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wide the audio frame and, so, is twelve bit mono. Both the hub control frame and 
the data control frame are a single byte wide. 

Figure 4A is a timing diagram showing how messages and data are 
exchanged between the local nodes 1 1 8 and the remote nodes 1 20 (through hub 
5 ports 1 1 6) across the backplane 1 06 using a data structure for example in Figure 4B. 
The backplane 106 includes a data bus for both audio data and intercom data, an 
address bus, a control bus and several control lines. For the preferred embodiment, 
the backplane 106 includes an eight bit Address Bus (A 7- AO), with addresses being 
serially cycled, 0 - 200 in a burst at the 10 MHz backplane clock rate, i.e., one burst 

1 0 in every frame of the 48KHz clock cycle. Addresses are assigned during 

initialization as described hereinbelow. Each address corresponds to a possible node 
in the network 100. The backplane includes stereo audio on two 18 bit channels. 
Audio Bus (ADL17-ADL0 and ADR17-ADR0), a right and left channel. Intercom 
data is provided as mono audio on a 12 bit Intercom Bus (II 1-10). Bus data is 

1 5 latched on the positive going edge of a Backplane Clock (BPCLK). An eight bit 
Control Bus (C7-C0) provides control data information for controlling 
communication among devices connected to the backplane 106. The Control Bus 
Status bit (CBS) signals hub ports connected to the backplane 106 when the control 
bus is active. A Frame Clock (FCLK) line is provided for synchronizing the hub 

20 ports 1 16 to the backplane 1 06. A Global Reset (Greset) signal initiates a hub wide 
system reset. A passive pullup Need Initialization (*NEEDJMT) signal is pulled 
low by any device connected to the backplane that needs initialization. 

FCLK synchronizes the entire network at the audio data-sampling rate, 
preferably 48Khz, although it may be 44. 1 Khz. Generally, the network sampling 
25 rate determines the number of possible addresses that can be polled at one time, and 
a different sampling rate may be selected with a corresponding adjustment in the 
number of addressable features. Since the entire network is synchronized to FCLK. 
all data sources and sinks (nodes 1 16, 120) must operate at the selected sample rate 
or some sub multiple thereof, i.e., 24Khz or 12Khz. 
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FCLK also synchronizes the hub ports 1 1 8 to the backplane and to the 
address bus. Further, the preamble signature synchronizes hub port 1 1 8 to remote 
node 120. Since the hub ports 118 transmit a packet every FCLK cycle, the 
preamble provides a precise event which is detectable at the remote nodes 120 for 
synchronization. Generally, all audio and intercom data conversion processes must 
be synchronized to the preamble detection to minimize aliasing. Thus, to maintain 
synchronization, each remote node 120 must initiate a transmission to its 
corresponding hub port 1 16 within one frame cycle of receiving a pocket. 

Sampled audio data is presented to the backplane 106 on a polled address 
basis, preferably sampled at forty eight thousand samples per second (48KSPS). 
Alternately, any suitable sample rate may be selected such as 44.1KSPS, for 
example. Thus, the backplane operating at a lOMhz BPCLK clock rate can support 
up to 200 addresses at this 48KSPS-frame rate. Accordingly, cycling through 
addresses 0 through 200 at the backplane clock rate in a burst, one burst of 0-200 
every frame clock cycle, each value addressing an audio source/sink (either at a local 
node 1 1 8 or at a remote device connected to a hub port 1 1 6) in the network, each 
addressed audio source/sink being presented with or providing data in turn. So, 
when an address is presented on the backplane 106. the appropriate control bus 
signals, intercom data and audio data for the selected node are also present on the 
backplane. For example, a person may be using a remote station 1 1 0 to transmit an 
intercom message, while an audio clip may be provided to a local station 108. 
During each address burst, when the address corresponding to the remote station 110 
is on the address bus, the intercom data is placed on the backplane intercom bus and, 
sampled audio is made available when the address of the local station 108 is on the 
address bus. Other stations remain passive, monitoring the bus for audio or intercom 
data that may be directed to that particular station or feature. 

Figure 5 is a timing diagram for initialization wherein addresses are assigned 
to attached devices. In each network 100, a single hub module 104 is assigned as 
backplane master. Preferably, backplane master hub module assignment is 
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designated for a single unique slot in entertainment hub 102. although any suitable 
way of assigning a master may be substituted, e.g., jumper pins selecting a backplane 
master. The single hub module 104 master provides the drive signals for the Frame 
Clock. Backplane Clock. Address Bus. and Address-in-Use signals. The hub 
5 modules are interchangeable and any one may serve as backplane master, provided it 
is placed in the master slot position in the entertainment hub 102 (or otherwise 
selected). Thus, the hub interface function 130 includes master control functions 
that are disabled unless the particular hub module 1 16 is selected as master. The 
backplane master hub drives the backplane signals during normal operation and 
10 drives initialization signals during the network initialization process. Other devices, 
i.e.. those not the backplane master, accept these signals as inputs. 

During initialization the CI, C6, C5 and CO control bus lines are used by the 
backplane master to provide individual initialization control. The C7 line is a 
contention/address acquisition (CONT/*ACQ) signal which is generated by the 

15 backplane master to coordinate between a contention cycle and an address 

acquisition cycle in the period labeled 150. The C6 line is a ready for initialization 
(INIT-RDY) signal that, when high, indicates that a device attached to the backplane 
is ready to start the initialization process. The C5 line acts as an address in use 
(ADD-IN-USE) signal indicating that a device address is already assigned to a node 

20 or port. The CO line is a contention (CONTJBIT) signal both during initialization 

and during normal operation contention. After the last device has been configured in 
the period labeled 152, initialization is complete. Normal backplane operation of 
Figure 4 begins in the period labeled 154. 

Figure 6 is a state diagram showing how the preferred local communication 
25 network 100 may be initialized. Network Initialization 160 is an automated process 
that occurs in the hub modules 1 04 on first power up 1 62 or, after a REINIT button 
(if included) has been pressed to request initialization. The process proceeds through 
three major phases: remote node scan 164, contention 166 and address acquisition 
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1 68. Each feature at a hub port 1 1 6 or local node 1 1 8 requires at least one backplane 
address for normal operation, which is assigned during initialization. 

First, on first power up 1 62 every device asserts the *NEED_INIT line, 
pulling it low^ to indicate to the backplane master that attached network devices need 
5 initialization. At the initial power up 162, the hub ports 116 provide powder to 
corresponding connected remote nodes 120 and after a preset delay send a null 
packet that the remote node 120 uses for synchronization. Each remote node 120 
responds returning a null packet that indicates the number of audio channels needed 
for that particular station or feature. Coincidental!} 7 , each remote node 120 also 
10 indicates if it needs additional audio channels by placing a non zero value in the left 
and right frames of a corresponding returned audio channel. Then, the remote nodes 
120 provide the null packet for a selected minimum scan time. If any of a remote 
node's audio channels are unused, then the unused frames are driven to all zeros 
(OOOOOh). Each corresponding hub port 140 requests addressing for each filled (non- 
15 zero) audio frame, with even' requesting hub module 104 or feature card 108 
holding the INIT_RDY line low during the remote scan sequence 164. 

Following the remote node scan 164. every hub port 1 16 and each feature 
card 108 configures its backplane-connected audio bus port as a passive high, active 
low r I/O port. Then, the unassigned hub ports 1 16 and feature cards 108 begin 

20 shifting their respective unique serial number (preferably a factory-set 36-bit 

number) onto the CONT_BIT line synchronized by the frame clock signal, while 
simultaneously monitoring the CONT_BIT. If for any monitoring device, the value 
of the CONTJBIT does not match what it shifted out. then another device is also 
requesting initialization, i.e.. devices are in contention; and, each unmatched device 

25 discontinues shifting its serial number out and releases the passive pullup 

CONT_BIT line for the remainder of the contention cycle. Each matching device 
continues to write their serial numbers to the CONTJ3IT until, eventually, only a 
single device remains actheh requesting addresses. The remaining unmatched 
devices, i.e., those that have placed their respective CONT_BIT output in a high 



5569-69491 



-14- 




impedance state, wait until the next contention cycle, when the next unassigned 
device is selected. The matching device proceeds to the address acquisition cycle 
168. 

5 For each address acquisition cycle 168, again synchronized by the FCLK 

signal, the backplane master sequentially cycles through the all addresses as the 
matching device monitors the passive pullup * ADD_IN_USE line. Each previously 
configured device asserts the *ADD__IN_USE line as each of its addresses appears 
on the address bus. When an available address is identified (i.e.. the ADD IN_USE 
1 0 line is not asserted), the backplane master assigns the identified available address to 
the requesting internal hub port. Unassigned devices continue monitoring, 
identifying and requesting addresses until all port address assignment requirements 
have been fulfilled. As each acquiring device has completed its configuration cycle, 
it releases the *NEED__INIT line and waits for the initialization process to complete. 

1 5 The contention cycle 166 and address acquisition cycle 1 68 are repeated until 

all attached devices have been configured, as indicated by the *NEED_INIT line 
being released high and then proceeding to Normal Operation 1 70. On each 
subsequent power up 162. unless a new device has been added. *NEED_INIT will 
not be pulled low and so, will be high (all assignments having been retained in local 

20 or non-volatile storage) and the system proceeds directly to the Normal Operation 
170 state. 

After initialization 160 and upon commencing Normal Operation 170, 
additional local nodes 1 18 or hub modules 1 16 may be added to the network by 
powering dow r n the network 100, attaching the devices to the entertainment hub 102, 
25 another powering up to re-execute the initialization process 160. On power up the 

newly-attached device asserts the *NEED_INIT line low. In response, the backplane 
master then enters the Initialization process 160, assigning addresses as required. 
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Additional remote nodes 120 may be attached to the network ("hot plugged") 
at a configured hub port 116 and so, do not need to be initialized. Further, if remote 
audio sources/sinks are attached to an existing remote node and the 
attachment/replacement reduces or does not change the number of sources/sinks at 
5 that node. Normal Operation 170 may continue uninterrupted. However, if the 
number of audio sources/sinks is increased, e.g.. a single audio source/sink at a 
remote node is replaced with a multiple audio sources/sinks, a power down cycle 
162 must be initiated to restart the initialization process 160. Then, when each hub 
module 104 scans its hub ports 1 16 through the remote node scan cycle 162, the 
10 added sources/sinks are detected and identified by asserting the *NEED_INIT line. 

By contrast, removing nodes from the network, typically, does not require 
reinitialization. Remote nodes ma}' be physically removed from the network 100 for 
example, by simph disconnecting from the serial stream 1 14 cable or by turning off 
the device or remote feature card 112. The removed device's hub port retains its 

1 5 address so that the remote node 120 may be re-attached later and it may seamlessly 
begin to function provided a network re-initialization 160 or a power cycle 162 does 
not occur before reattachment. However, if the network is re-initialized or power 
cycled after removal, reattaching the device requires a re-initialization 160, just as if 
a new device were being added. Initialized local nodes 1 18 also can be removed and 

20 reattached to the backplane without re-initialization, provided the reattached local 

node retains its address information. Otherwise, the local device should be reset and, 
network power cycled to re-initialize the new/replaced local device and node. 

On the first initialization of a hub module 104, each hub port 1 16 acquires a 
backplane address. The hub port 1 16 then signals its address to its connected remote 
25 node 1 20, which may or may not use or respond to the address. Hub ports 1 1 6 do not 
require a response (ACK or ERR messaging) to their own initiated messages. 
However, each remote node 120 must signal its corresponding hub port 116 using a 
hub message to change the listening settings of the hub port 1 16. The corresponding 
hub port 1 1 6 responds either with an ACK or an ERR response message within 2 
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frame clock cycles. The serial data stream may include hub control and data control 
messaging when initiated by a local node 1 18 or hub port 1 16 in addition to audio 
and intercom data which are transferred continuously. Hub control and data control 
messages are selectively included in packets and passed in the serial stream, one byte 
5 per packet. The hub control message frame designates an audio or intercom channel 
in remote nodes 120. Each remote node 120 queries its corresponding hub port 1 16 
for its present sourcing node and its listening channel settings, as well as, setting the 
listening channels. Automatically, on first hub power up or on re-initialization, each 
hub port 1 16 selects the sourcing channel. Each frame cycle includes only one byte 

10 of hub messaging in the huh control field. As each hub message is passed, byte by 
byte, the entire message is re-assembled at the receiving node, i.e., either at the hub 
module 104 at one end or at the remote station/feature card 110, 1 12 at the other. 
Preferably, each hub message is four (4) bytes wide and prefaced with an attention 
byte (e.g.. FFh) to notify the intended receiver (either hub module 104 or remote 

1 5 station/feature card 110. 112) that a hub message is to follow. 

The attention byte may be followed by a command directing the receiving 
node regarding how to handle the audio data on the channel. Examples of 
commands provided in this second, command byte are shown in Table 1 below. 



TABLE 1 



NUL 


OOh 


'do nothing, idle value 


SET 


Olh 


'set the channel to value 


GET 


02h 


'get the channel's value 


ACK 


03h 


'acknowledge message with channel and value returned 


ERR 


04h 


'error with channel and value returned 



25 The command b>te is followed by a channel byte that, preferabh . includes 

two (2) four (4) bit fields. The first 4-bit field indicates whether the receiving device 
is receiving or sending audio and. so, is a sink or a source. The second field selects 
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an audio field, i.e.. intercom, audio L audio 2, audio 3 and audio 4 for the 
received/sent audio data. The command byte is followed by an eight bit value 
ranging from 1 to 200 and indicating the channel address. 

Local control messaging provides control for peer to peer communication 
between nodes, primarily for sharing information or controlling either a local feature 
card 108 or remote feature card 1 12. The control message structure may be similar 
to that of hub messaging wherein one byte in the data control field is passed per 
packet. However, local control messaging within the communication hub 102 may 
be quite different. Each local control message contains a multibyte preamble, a 
destination address, a source address, an indication of the message size, the message 
and a checksum value for verifying the message validity. Within the communication 
hub 102, control information is sent over the control bus (C7-C0) which also is an 8 
bit wide, contention bus. All hub nodes 116 and local nodes 1 18 have access to this 
bus and must contend for control. Preferably, the control bus is passive pull up. 
active pull down. So. when all connected nodes are idle, the bus is all ones (FFh) 
indicating that a node is not accessing the bus. 

Figure 7A shows a state diagram 1 80 of how a node gains access to the 
control bus. First, before beginning its transmission, in state 182, nodes requiring 
access monitor the bus until a quiet time is detected. If two or more nodes attempt to 
communicate simultaneously, an arbitration process 184 assigns priority based on 
the control message preamble. For confirmation, the values on the control bus are 
mirrored back to the remote node via the serial stream data frame, delayed by one 
frame. Local nodes are directh attached to the contention bus and compensate for 
the delay to remote nodes during the arbitration process. 

Figure 7B shows an example of the preferred control message structure. The 
control message preamble, which is preferably 8-10 bytes, is utilized for bus access 
arbitration. Each preamble byte is one of two possible values, either zero (OOh) or 
one (Olh) and sets the contention bit CONT_BIT in the control bus. The 10 byte 
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preamble string represents a pseudo-random 10 bit binary number pattern, with the 
lowest 1 0 bit value has the highest bus priority. The preamble is followed by a 
destination address which is a single byte that contains the network address of the 
destination node, A single byte source address follows the destination address and 
5 contains the network address of the message source node. Two bytes are assigned to 
designate the Number Of Bytes (NOB) in the control message payload. The payload 
may be as large as 64K Bytes and is the substance of the control message or data. 
Finally, the payload is followed by a two byte checksum that is the tw T os complement 
of the sum of the entire message less the preamble and the checksum itself. 

10 As noted hereinabove, idle nodes monitor the control bus for activity in 182. 

When the control bus is quiet and the *CBS bit is one, a node may attempt to begin a 
transmission by asserting *CBS (pulling it low) in 1 84 and, begin bus arbitration by 
sending the preamble. The transmitting node must monitor its message transmission 
(via the return packet or directh at the control bus) to negotiate for control of the 

1 5 bus, detect a collision with another message, or to detect a serial stream data error. 
The node attempting to initiate transmission monitors the value of the preamble 
returned from the bus to confirm whether that node has access to the bus. If the 
preamble value is returned without error, the node has access to the control bus and 
continues to transmit in 186. However, if the node does not have access it releases 

20 the *CBS bit, in 188, ceases transmission and waits until the control bus is idle 
before attempting to transmit again in 184. 

Figure 8 is an example of a control message reception state diagram 190. 
Nodes that are directly connected to the control bus (i.e.. hub ports 116 and local 
nodes 118) through the backplane continually monitor the bus and the *CBS bit in 
25 192. Message transmission begins with the assertion of the *CBS bit in 194 by the 
transmitting node. Each monitoring node parses the message header, which includes 
the preamble, destination address, source address and NOB fields in 196 to 
determine if the node is the message destination. Either the message may be 
directed to a specific address or it may be broadcast, for example as an intercom 
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message. If the message is addressed to a node in 198Y, that node continues 
processing the message. Otherwise, in 198N. the nodes discard the message and 
continue to monitor the *CBS bit until it returns to idle in 192, to receive the next 
new message. 

As described above, addresses between 1 and 200 are assigned to each 
connected node in the initialization process 160. A remote node 120 sets its address 
by querying its corresponding hub port for its remote node address(s). Address OOh 
is reserved for broadcast messages and so. no node is assigned this address. All 
nodes process broadcast messages. Further, one or more addresses may be reserved 
for the conference intercom function and only the conference feature node may 
acquire this reserved address. 

For synchronization, all backplane address locations must be polled within a 
FCLK cycle. Further, each serial stream transmission cycle (one upstream and one 
downstream) c\cle completes, preferably, in less than a single frame clock cycle. 

1 5 Figure 9 is an example of a typical preferred embodiment home 

communication system 200 with elements identical to the basic system 100 of Figure 
2 labeled identically. In addition to the entertainment hub 102, several room 
stations. 202. 204, 206, 208, 210 and 212 are shown that are physically located at 
different zones or rooms. A video doorbell 214 is locatable at an exterior door. A 

20 main communications panel 216 is provided for control from a conveniently selected 
location. Outside temperature sensors 218 are locatable to provide external 
temperature information to the system that may be retrieved at any room station 202- 
212 or other connected peripheral. In addition, since the network 200 is a digital, 
one or more computers 220. printers 222 may be attached, directly, to send or 

25 receive communications or entertainment data, the remote node/remote station 
feature being provided as a hardware feature of the computers 220 or in software 
executed by the computer 220. A wireless keyboard 224 may communicate with the 
system 200 over the computer 220 or directly, e.g. through an IR port 126. Further 



5 
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access to the Internet may be provided, either through the computer 220 or through a 
direct connection at the hub port, e.g., through a cable modem or digital subscriber 
line (DSL) modem. 



A home theater system 226 may be connected to the network. The home 

5 theater system 226 may be capable of playing or displaying multimedia data received 
from the network or, of sending multimedia data, such as audio files over the home 
communications system 200 to individual room stations 202-212. for example. A 
telephone 228 may be included, such that music from the network is played as 
background music when the telephone 228 is placed on hold and, to provide voice 

1 0 mail that is stored on the system 200. An entertainment/sound system 230 may be 
connected to the network and located in a media room. Like the home theater 
system 226 the sound system 230 can play audio data directly received from the 
network and may be capable, for example, of placing audio data extracted from an 
audio cassette onto the network. A television 232, e.g., digital audio TV or high 

1 5 definition TV (HDTV), can be connected to the network 200. The television 232, 
like the home theater system 226, and the sound system 230, can play audio or 
multimedia data directly from the network and is capable of placing multimedia data 
or audio data on the network 200. Also, local, specialized controls may be made 
available at different zones throughout the network. These local controls 234 can 

20 provide, for example, home or away settings to vary the capability of the system. 

Temperature control 236 for heating and cooling may be connected for independent 
control at any station 202-212. Also, a programmable logic controller (PLC) 238 
may be adapted, if available, allowing independent remote control of lights 239 and 
other such controlled appliance from enabled stations 202-212. 

25 Figure 10 is an example of the room station. 110. In this example, the room 

station includes multiple buttons. 240, 242. 244, 246, 248, 250, 252, 254, for 
selecting various functions from the room stations. A microphone input 256 is 
provided for receiving vocal input and a small speaker 258 is included, if 
loudspeakers are not provided, for intercom function. Jacks, 260, 262, are also 
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included for audio input. A digital communication jack 264 in this example, an 
ethernet connection or category 5 wiring, is also included for connecting the local 
station 1 10 to the network. Also, a display 266, such as a liquid crystal diode (LCD) 
display, is included, providing a simple local graphical interface. Thus, preferred 
5 room stations include the capability to act as an audio source unit, an audio receiver 
unit and an intercom unit. Sound tone and volume may be set at each individual 
room station 110 independently of settings at other room stations 110. Further, a 
door station does not require the audio source function and, so, a suitable door 
station results by omitting the audio function from a room station 1 10. 

1 0 Figure 1 1 is a block diagram of a remote station 110. Remote station 1 1 0, 

typicalh. includes a serial data exchange 270. a programmable digital loop filter 
272, an audio compression/decompression (CODEC) 274, a microcontroller or 
microprocessor 276. a local interface 278 and local storage 280. The local interface 
278 may include a display 282, such as a LCD display 266, for displaying status 

1 5 information and time, for example, and individual buttons 284 for manual input, 
such as providing commands to connected room stations, remotely disabling 
command input from other stations. Commonly used commands may be maintained 
in a command menu provided at the display 282. The local storage 280 may be any 
suitable storage, in particular random access memory (RAM). Further, the RAM 

20 may be static RAM (SRAM), dynamic RAM .(DRAM) or non- volatile RAM such as 
what is typically referred to as Flash memory. As described hereinabove, power 286 
is supplied over the high speed serial data channel 1 14. 

The serial data exchange 270 may be a transceiver or, a phy chip as described 
hereinabove with reference to the hub module 104. The audio CODEC 274 provides 
25 an analog/digital interface between analog audio (provided to the local station 1 10 
from the network or provided by the local station 1 10, e.g., from a radio tuner) and 
digital audio to/from the programmable digital loop filter 272. The CODEC 274 
converts digital audio data from the programmable digital loop filter 272 into analog 
audio for a local audio performance and converts analog audio received at the local 
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station into digital audio data which is provided to the programmable digital loop 
filter 272. Preferably, the audio CODEC 274 is a Crystal CS4227 6-channel 20-bit 
CODEC chip from Cirrus Logic. The preferred CODEC 274 can support at least 
one 18-bit stereo/audio channel and one intercom channel. Additional, optional 
channels may be included. The non-volatile storage 280 locally maintains stored 
information and program control including a bootstrap program for bootstrap start 
up of the microcontroller 276. Preferably, the non-volatile storage is flash memory 
or EEPROM and may include up to several megabytes of storage. The serial data 
exchange 270 extracts received serial data from the high-speed serial data channel 
114 and, embeds the serial data clock into serial data for transmission across a high- 
speed serial data channel 114. 

Figure 12 is a block diagram of the programmable digital loop filter 272. 
The programmable digital loop filter 272 includes a receive buffer 290. a transmit 
buffer 292. a CODEC interface 292 and a microcontroller interface 296. The receive 
buffer 290 is essentially a serial-to-parallel shift register receiving data (RXD) 
clocked by receiver clock (RXCLK) from the serial data exchange 270 and converts 
that serial data to parallel data which is provided as audio channel data on lines 298 
to CODEC interface 294 and hub control and data on lines 300 to microcontroller 
control interface 296. The receive buffer 290 also provides intercom data 302 to the 
CODEC interface 294 and extracts a hub sync signal 304 from the received data. 
The transmit buffer 292 receives parallel data from the CODEC interface 294 and 
microcontroller interface 296 which it converts to serial data (TXD) that is provided 
to the serial data exchange 270, clocked by transmission clock (TXCLK). The 
transmit buffer also provides a transmit enable signal (TXEN) that indicates when 
the serial data from the station should be transferred through the serial data exchange 
270 across the high-speed serial data channel 1 14. 

Parallel data from the CODEC interface 294 includes intercom data on lines 
306 and audio channel data on lines 308 as well as hub control and data from the 
microcontroller interface on lines 310. The CODEC interface 294 passes received 



data from the receive buffer to the CODEC 274 and passes data from the CODEC 
274 to the transmit buffer 292 for transmission across the high-speed data channel 
114. The microcontroller 296 presents data from the receive buffer 290 to the 
microcontroller 276 and passes data from the microcontroller 276 back to the 
5 transmit buffer 292. The hub sync signal 304 is generated when the receive buffer 
290 senses a preamble in the receive data stream, which initiates a pulse that is the 
hub sync signal 304. Additionally, the receive buffer 290 parses serial data from the 
serial data exchange 270 and identifies audio data for the audio channels 298 and 
control data and control signals 300 for the microcontroller interface 296. The hub 
10 sync signal 304 synchronizes the remote station to the hub. Although the data may 
be received at the remote station somewhat delayed from the original transmission, 
due to transmission channel delays, for example, the extracted signal is a true replica 
of what the hub transmits. Likewise the hub receives an exact replica of what the 
remote station transmits. 

1 5 Local feature cards 108 may be formed by directly interfacing the hub 

function control 130 of the hub module with the CODEC 274, thereby providing the 
audio function directly to the hub control function which interfaces the audio digital 
data to the backplane instead of to hub ports. Local feature cards 108. may include, 
for example, a radio tuners providing broadcast radio, e.g., AM, FM and wideband 

20 radio such as weather band radio or television broadcast bands. 

Thus, the multi-zone media network of the present invention provides digital 
audio available for use at each zone of a structure or different rooms of a house. 
Further, multi-zone media network includes room stations that can inject audio into 
the data stream and onto the network. So, at each room station is converted from 
25 digital data to analog audio and locally amplified for clear CD quality sound. Since 
the audio is transferred over the preferred multi-zone media network as digital data, 
high-cost, low-loss wiring that is required to route high quality audio is unnecessary. 
Instead, relatively inexpensive CAT 5 wiring may be used to pass data from the hub 
to the room stations. Further, the room stations independently control and select 
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what is played in the room from one of several audio data channels being streamed, 
rather than merely play what is being broadcast. In addition, each remote station 
itself can broadcast or receive independent of and simultaneously with other remote 
stations. Also, each remote station can be programmed for individual specific needs 
5 such as including radio station presets on remote stations equipped with a radio 
tuner. Alarms or limited functionality may be included, such as to the ability to 
monitor another remote using the multi-zone media network's intercom function. 

While the invention has been described in terms of preferred embodiments, 
those skilled in the art will recognize that the invention can be practiced with 
1 0 modification within the spirit and scope of the appended claims. 
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